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METHOD AND SYSTEM FOR OBJECT ORIENTED APPROACH AND DATA 
MODEL FOR CONF1GURE-TO-ORDER MANUFACTURING SYSTEM 



FIELD OF THE INVENTION 

The present invention relates to automated product fulfillment and in particular, an object 
oriented approach and data model for configure-to-order computer manufacturing systems. 

BACKGROUND OF THE INVENTION 

The computer manufacturing industry has undergone several major changes in recent 
years. One of these major changes has been in the area of customized or personalized computer 
systems. Today, consumers essentially can build their own systems based on their unique 
requirements. For example, a customer can select hardware components (e.g., types and quantities 
of memory, DASD, CPU, PCI option cards, etc.), and the placement of the hardware within the 
system (e.g., which slots, bays, and riser cards the devices are installed in and how they are cabled). 
Moreover, the customer can select software (e.g., operating systems, applications, and device 
drivers), system settings (e.g., boot sequence, RAID configuration, and operating system and 
network settings such as computer name, IP addresses, subnet masks, etc.), and other services 
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(e.g., placement of asset tags on exterior of machines, saving and printing information unique to the 
machine). Thus, the customer can build a configure-to-order system that meets the customer's 
exact specifications and requirements. 

Providers of configure-to-order fulfillment systems face numerous challenges. First, given 
the variety of hardware components, software, settings, and services available in a computer system 
from which the customer might choose, the configure-to-order system must be able to handle the 
various permutations created by the customer. Because of the enormity of this task, current 
configure-to-order systems do not afford the customer full control over customization. Rather, a 
"machine type model" approach is taken, wherein a grouping of components is represented by a 
part number or model name. For instance, a particular part number might signify a specific CPU 
with memory loaded in a particular slot. The manufacturing system understands the meaning of the 
part number and builds the corresponding product. In this approach, the customer is allowed a 
limited range of predetermined choices, such as processor type, memory, and perhaps exterior 
color. Accordingly, while the number of combinations is manageable for the provider, customer 
flexibility is sacrificed. 
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In the alternative, custom preferences can be communicated to a customer service provider 
who then records or enters the information on an order form (text based), which is then used during 
the post ordering process. This system, however, is inefficient because the information on the order 
form might be inaccurate or incomplete, or both, thereby causing delays in manufacturing while the 
customer is contacted for more information. In addition, the information on the order form must be 
retyped or otherwise recreated for use in other processes besides assembly, such as testing and 
software preload. Moreover, if the assembly process is manual, an assembly worker can 
misinterpret the information on the order form. 

Thus, current configure-to-order manufacturing systems either lack the versatility to allow 
a customer to have full control of the ordering process, or are inefficient in their operations, 
requiring extensive customer contact after the initial order time. What is needed is a configure-to- 
order manufacturing system and process which allows the customer flexibility at the initial order 
time so the customer can choose all of the configuration and personalization options for the 
product. The system and process should automatically capture this information and create a 
product plan that meets all of the development rules for the product and installed options and 
software for correct operation. Moreover, the product plan should describe to the assembly 
worker what steps must occur to build the product, preferably in a simple picture based manner, 
describe to the automated test system the configuration of the machine for verification purposes, 
i.e., to validate the worker correctly assembled the machine and that the parts are functioning 
correctly, and describe to the automated preload system the software and personalization that must 
occur. Finally, the product plan should provide information that can be used by service and support 
for repairs or maintenance. The present invention addresses such a need. 
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SUMMARY OF THE INVENTION 

A method and system for product fulfillment in an automated manufacturing system is 
disclosed. The method and system of the present invention includes obtaining requirements for a 
product from a customer. The method and system further includes creating a plan from the 
requirements using a descriptive language. The plan is then conveyed to an automated 
manufacturing system for use in manufacturing the product. 

An object oriented approach and data model of the present invention allows customization 
and personalized information to be captured completely and accurately at the initial order time such 
that follow-up calls to the customer are eliminated or greatly reduced. Moreover, the present 
invention provides an end-to-end automated process which enables a manufacturer to build the 
customized product in a high-quality, cost-effective and repeatable manner 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 illustrates a block diagram representing a product fulfillment system in accordance 
with one embodiment of the present invention. 

Figure 2 illustrates the product fulfillment process according to the present inventioa 
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DETAILED DESCMEPTION 

The present invention relates to automated product fulfillment and in particular, to an 
object oriented approach and data model for configure-to-order product manufacturing systems. 
The following description is presented to enable one of ordinary skill in the art to make and use the 
invention and is provided in the context of a patent application and its requirements. Various 
modifications to the preferred embodiment and the generic principles and features described herein 
will be readily apparent to those skilled in the art. Thus, the present invention is not intended to be 
limited to the embodiment shown but is to be accorded the widest scope consistent with the 
principles and features described herein. 

The object oriented approach and data model of the present invention provides the means 
for capturing customized order information in a clear, non-ambiguous, structured, and extensible 
manner, and for manufacturing the product in a high-quality, cost-effective, and repeatable manner. 
Although the following discussion is directed primarily to configure-to-order computer systems, it 
is important to note that the present invention can be implemented for products other than 
computers. Thus, the present invention is in no way limited to computer or information processing 
products. 

The object oriented approach and data model of the present invention addresses the 
problems associated with configure-to-order manufacturing systems discussed above. By using a 
descriptive language referred to as Architected Object Data ("AOD") to describe the custom 
ordered product, the manufacturing process from start-to-finish can "speak" the same language. 
The present invention merges customer requirements, population rules (e.g., sequences for filling 
CPU, memory, expansion card, DASD slots, etc.) and configuration rules (e.g., setting jumpers, 
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changing CMOS setup values, etc.) into an accurate and comprehensive product plan that can be 
passed onto, and used by, an automated manufacturing system. 

As will be described in detail below, AOD is a descriptive language that can be used as a 
data model for personal computers or other systems. The product plan, also known as a process 
AOD, describes fully every aspect of the product, from the hardware components to the types of 
connections between devices. Each process downstream from the ordering process understands 
AOD and uses the product plan to perform its function, whether it be automated testing, software 
loading, or assembly. 

AOD is hierarchical and object oriented in nature. The following is a description of the 
AOD data model. 
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AOD Object Hierarchy 

The AOD format provides a hierarchical structure used to describe a product, such as a 
personal computer. For example, Table 1 illustrates an example of a partial object hierarchy in 
AOD for a simple personal computer. 

TABLE 1 



Level Object 

001 + - UNIT (1) 

002 + - CHASSIS(l) 

003 +- PICTURE (1) 

004 + - SCHEMATIC(l) 

005 + - BAYPLANAR (1) 

006 +- PLANAR (1) 



The "UNIT' object is at the top of the hierarchy, with first level child objects under it. The first 
level child objects can then in turn be parents to additional levels of child objects. Thus, CHASSIS 
(1) is a first level child object, and PICTURE (1) is a child of CHASSIS (1). SCHEMATIC (1) 
and BAYPLANAR (1) are also children of CHASSIS (1), and PLANAR (1) is a child of 
BAYPLANAR (1). 

Because of the modular nature of AOD, new objects can easily be added to the system 
when new products or components become available. Thus, the customer's choices are 
continually being updated and optimized. 
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General AOD Syntax 

AOD uses the following general syntax: 

Object(Instance).Attribute = Value 

Object 

An object in AOD is a model or data template of a component. This template will have 
attributes that relate to that component (physical or logical). An object or group of objects is 
chosen to describe each physical part and each logical part. A planar, chassis, PCI cards, memory, 
and processor are typical physical parts, while software images and partitioning information are 
logical parts. Thus, for example, an object called "PCI" will be used to represent each PCI device 
in the unit to be built, and an object called tc PLANAR" will be used to represent each planar in the 
unit. 

Instance 

The instance of an object is an occurrence of an object. This can also be thought of as 
a specific usage of an object template. The instance number is a positive whole number 
starting at 1. It is used to differentiate between multiple occurrences of the same object type. 
Thus, for example, two different PCI objects will be represented by PCI(l) and PCI(2). 
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Attribute 

An attribute is a characteristic that is associated with an object. For example, attributes 
associated with a PCI object might be the PCI's vendor identification and device identification, and 
whether the PCI is an onboard (soldered) device or an option card. 



Value 

Each attribute is assigned a value, which is designated by the specific attribute. Thus, the 
value of an attribute might be a string of text, a number, a comma separated list of numbers or 
words, as defined by the specific attribute. For example, where an attribute associated with a CPU 
object might be speed, the value for the speed attribute can be 667_MHz. 

In Table 2, AOD for a CPU device is provided in column 1, and explanative comment is 
provided in column 2. 

TABLE 2 



AOD 

CPU(l)X>esc=IntelP3 

CPU(1)BOM_PN=09N9215 

CPU(l)TestClass=cpu 



CPU(l).Speed=667_MHZ 



CPU(l).BusSpeed=133_MHZ 

CPU(l).LlCache=32_KB 

CPU(l).L2Cache=256_KB 

CPU(l).SmbiosType=ll 

CPU(l).SmbiosDesignation=CPUl 



Comment 

Description of the object 
Part number of the object 

Indicates type of test that will be done in 

manufacturing 

CPU speed information for 
automated software verify 

CPU bus speed information 
CPU LI cache information 
CPU L2 cache information 
CPU SMBIOS Information 
CPU SMBIOS Information 
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AOD Syntax for Linking Parent and Child Objects 

Because AOD is a hierarchical language, it is important to be able to link child objects to 
their parents using AOD syntax. This is done using the general AOD format, but with a more 
specific usage of the syntax: 

ParentObject(Instance).ChildObject( ) = Value 

ParentObject (Instance) 

A ParentObject is the object that is being defined to be hierarchically above a ChildObject. 
The instance is defined above and identifies the parent object specifically. 

Child Obiect( ) 

The ChildObject is the object that is being defined as being hierarchically below, or owned 
by the ParentObject. As defined above in the general syntax, the ChildObject occupies the position 
held by the attribute associated with the ParentObject. The ( ) immediately following the 
ChildObject is the specific indicator that indicates the attribute is referring to a child object, and that 
this AOD is linking a parent and child object. 
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Value 

The value in the Parent/Child AOD syntax is a number or range of numbers that indicate 

which instances of ChildObjects should be linked to the ParentObject 

Table 3 illustrates a sample of AOD for two Parent/Child links. 

TABLE 3 

PLANAR (1).PCI()=1 

PLANAR (l).ConnectorMem ()= 1:2 

In the example in Table 3, PLANAR (1) is the parent of PCI (1) object. The second link indicates 

that PLANAR (1) is the parent of ConnectorMem (1) and ConnectorMem (2). 

AOD Syntax for Describing Device Connections 

It is essential to populate devices such as memory, DASD, CPUs, and option cards, using 
the correct connectors/cables. Thus, there should be and is a way to model proper connection 
information in AOD. This is done again using the general AOD format, but with a more specific 
usage of the syntax: 

ReceivingObj ect (Instance) . InstalledDevice=InstalledObj ect(Instance) 

and 

ReceivingObject(T^ance).LocatedDevice=InstaUedO 

ReceivingObjectflnstance') 

The ReceivingObject is the object which will receive an installed or located device. The 
instance number specifies which occurrence of the ReceivingObject is being referenced. 
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"InstalledDevice" and "LocatedDevice" 

The text strings "InstalledDevice" or "LocatedDevice" are specific attributes indicating that 
the AOD is describing a device connection and the nature of that connection. InstalledDevice 
signifies an electrical connection between devices. Typically, devices are electrically connected by 
cables or connecting members. LocatedDevice indicates that the ReceivingObject and 
InstalledObject are mechanically or physically connected. So, for instance, LocatedDevice is used 
to indicate into which bay a DASD device or power supply is physically mounted, and 
InstalledDevice can indicate into which PCI slot a card will be inserted. 

InstalledObjectflnstance) 

The InstalledObject is the device which is being installed onto the ReceivingObject device. 
The instance number specifies which occurrence of an installed object is being referenced. 

Table 4 is a sample of AOD illustrating device connections. 

TABLE 4 

ConnectorMem ( 1 ). InstalledDevice = Mem(l) 
ConnectorMem (2).InstalledDevice = EMPTY 
BayPower( 1 ).LocatedDevice=Power( 1 ) 
BayHdd(l).LocatedDevice = Ide(2) 

The AOD in Table 4 indicates that ConnectorMem(l) has Mem(l) electrically connected to it, 

whereas ConnectorMem (2) is empty. ConnectorMem can be a connecting member attached to a 

device or component. For example, a planar might have several connecting members into which 

other devices can be installed. Thus, an electrical connection is established between the planar and 

the device via the connecting member. 
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Referring back to Table 4, Power(l) power supply is physically mounted in BayPower (1). 
The AOD indicates where the power supply is located. DASD Ide(2) is physically mounted in 
BayHdd(l). 

Given these general syntax rules for AOD, a product, such as a personal computer, can be 
fully and accurately described in a structured and non-ambiguous manner. Table 5 illustrates a 
complete AOD product plan for a single personal computer with explanatory comments in 
parenthesis. 

TABLE 5 



AOD For ORDERJD [000100066023] 

UNIT( 1 ).MTM=6565CTO 
UNIT( 1 ).BOM_PN= 1 9K5277 

UNIT(1).CHASSIS0=1 

UNIT(l).DTAImage()=l 

UN1T( 1 ) . RFID S UPP ORTED=YE S 

CHASSIS(1).PICTURE()=1 

PICTURE(1).DESC=ATHENA Chassis 

PICTURE(l).FILE=ATHCHAS.jpg 

CHASSIS(l). SCHEMATICOl 

SCHEMATIC(1).DESC=ATHENA Chassis 

SCHEMATIC(1).FILE=ATHENA1 jpg 

CH AS S I S ( 1 ) . B AYPL AN AR0= 1 

CHASSIS(l).BAYPOWER()=l 
BAYPOWER( l).LOCATORTEXT= 
POWER1 

BAYPOWER(l). SCHEMATICOFFSET= 
10,10,30,30 

CHASSIS(1).BAYFDD0=1 
BAYFDD(l).LOCATORTEXT= 
FLOPPY DRIVE 



(Machine type and model) 

(Part number for the object) 

(Indicates there is 1 chassis child object) 

(Indicates there is 1 preload image) 

(Indicates system support rfid functionality) 

(Indicates there is 1 picture child for chassis) 

(Description of the picture) 

(File name of the picture (MFG assembly aid)) 

(Indicates there is 1 chassis drawing) 

(Description of the chassis drawing) 

(File name of the drawing (MFG assembly aid)) 

(Indicates their is one bay to put a planar) 

(Indicates their is one bay to put a power supply) 

(Text to tell operator how to identify 

power bay) 

(Coordinates of power bay on the chassis 
drawing) 

(Indicates there is one bay to put a floppy drive) 
(Text to tell operator how to identify floppy bay) 
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BAYFDD(1 ). SCHEMATICOFFSET=3 5,40,50,55 

CHASSIS(1).BAYHDD0=1 
B AYHDD( 1 ).LOC ATORTEXT=HDD BAY1 
B AYHDD( 1 ). S CHEM ATICOFF S ET=EMPT Y 
CABLEFDD(1).DESC=FDD CABLE 

C ABLEFDD( 1 ) . OPERATION=KITTING (Indicates MFG operation that will add part) 
CABLEFDD(l).BOM_PN=19K5277 

CABLEFDD(1).SCHEMATIC0=1 
CABLEFDD(1).PICTURE()=1 

CABLEFDD(l).CONNECTORFDD0=l 
CONNECTORFDD(l).FDDTYPE=FDDl 
CONNECTORFDD(l).LOCATORTEXT=FDD 1 
CONNECTORFDD( 1 ) .DriveName=ADRTVE 
CONNECTORFDD(l). SCHEMATICOFF SET=EMPTY 

CHASSIS(1).BAYDASD10=1 

B AYDASD 1 ( 1 ).LOCATORTEXT=D ASD BAY1 

BAYDASD 1(1). SCHEMATICOFFSET=EMPTY 

CHASSIS(1).BAYDASD20=1 
B AYDASD2( 1 ).LOCATORTEXT=D ASD BAY2 
B AYD ASD2( 1 ) . SCHEMATIC OFF SET=EMPTY 
B AYPL ANAR( 1 ).LOC ATORTEXT=PLANAR 
B AYPLANAR( 1 ). SCHEMATICOFFSET=EMPT Y 
PL AN AR( 1 ) . DESC= ATHENA PLANAR 
PL AN AR( 1 ) . OPERATION=KITTING 
PLANAR(l).BOM_PN=61H2571 

PLANAR(l).TESTCLASS=athenaplanar (Indicate tests that are associated with this 

Object) 

PLANAR(l).CONNECTORCPU0=l (Indicates there is 1 CPU connector) 

CONNECTORCPU(l).LOCATORTEXT=CPU 1 

CONNECTORCPU(l). SMBIOSDESIGNATION=CPU (Information on the CPU 

connector (for SW verify)) 

CONNECTORCPU(l). SCHEMATICOFF SET=EMPTY 

PLANAR( 1 ) . CONNECTORMEM()= 1 :2 (Indicates there are 2 memory connectors) 
CONNECTORMEM( 1 ) . LOC ATORTEXT=MEM 1 

CONNECTORMEM(l).SMBIOSDESIGNATION=DIMM 0 (Information on first 

memory connector (for SW verify)) 
CONNECTORMEM(l). SCHEMATICOFF SET=EMPTY 
CONNECTORMEM(2).LOCATORTEXT=MEM 2 

CONNECTORMEM(2). SMBIOSDESIGNATION=DIMM 1 (Information on the second 

memory connector) 

CONNECTORMEM(2). SCHEMATICOFFSET=EMPTY 

PLANAR( 1 ).PCI0= 1 (Indicates there is one PCI object on planar) 

PCI(1).DESC=ESS AUDIO ALLEGRO (Information on type of PCI device) 
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PCI(1).PCIADDRESS=BUS[00]DEV[12]FUNC[0] (Information on address of PCI device) 
PCI(l).OPERATION=KITTING 
PCI(l).BOM_PN=61H2571 
PCI( 1 ).TESTCLAS S=essaudio 

5 PCI(l).ONBOARD=YES (Indicates PCI is attached to planar (i.e., not a card)) 

PCI( 1 ). VENDORID= 1 25D (Vendor ID for the PCI device (for SW verify)) 

PCI(1).DEVICEID=1988 (Device ID for the PCI device (for SW verify)) 

PLANAR(l).CONNECTORAGP0=l 
CONNECTORAGP(l).LOCATORTEXT=AGP 1 
10 CONNECTORAGP(l ). SMBIOSDESIGNATION=AGP 

CONNECTORAGP(l). SMBIOSNAME=PCI 

CONNECTORAGP(l ).PCIADDRESS=BUS[0 1 ]DEV[00]FUNC[0] 
CONNECTORAGP( 1 ). SCHEMATICOFFSET=EMPTY 

PLANAR(l).CONNECTORPCI()=l :3 (Indicates there are 3 pci connectors on this planar) 
p5 CONNECTORPCI(l).LOCATORTEXT=PCI 1 

aJ CONNECTORPCI(l).SMBIOSDESIGNATION=l-PCI (Information on first pci 

Ui connector (for SW verify)) 

CONNECTORPCI(l).SMBIOSNAME=PCI 
£ CONNECTORPCI(1).PCIADDRESS=BUS[00]DEV[10]FUNC[0] 
gk CONNECTORPCI(l).SCHEMATICOFFSET=EMPTY 
jS CONNECTORPCI(2).LOCATORTEXT=PCI 2 

CONNECTORPCI(2). SMBIOSDESIGNATION=2-PCI 
Ci CONNECTORPCI(2).SMBIOSNAME=PCI 
yj CONNECTORPCI(2).PCIADDRESS=BUS[00]DEV[0F]FUNC[0] 
m CONNECTORPCI(2).SCHEMATICOFFSET=EMPTY 
J CONNECTORPCI(3).LOCATORTEXT=PCI 3 

y CONNECTORPCI(3). SMBIOSDESIGNATION=3-PCI 

^ CONNECTORPCI(3).SMBIOSNAME=PCI 

CONNECTORPCI(3).PCIADDRESS=BUS[00]DEV[0E]FUNC[0] 
30 CONNECTORPCI(3).SCHEMATICOFFSET=EMPTY 

PL ANAR( 1 ). CONNECTORC ABLEIDE0 = 1 :2 

CONNECTORCABLEIDE( 1 ).LOC ATORTEXT=PRIMARY IDE CONTROLLER 
CONNECTORCABLEIDE( 1 ). CONTROLLER=PRIMARY 
CONNECTORC ABLEIDE( 1 ). SCHEMATICOFFSET=EMPTY 
35 CONNECTORCABLEIDE(2).LOCATORTEXT=SECONDARY IDE CONTROLLER 

CONNECTORCABLEIDE(2).CONTROLLER=SECONDARY 
CONNECTORCABLEIDE(2).SCHEMATICOFFSET=EMPTY 
PL AN AR( 1 ) . CONNECTORC ABLEFDD0= 1 

CONNECTORC ABLEFDD( 1 ).LOC ATORTEXT=FDD CONTROLLER 
40 CONNECTORC ABLEFDD( 1 ). SCHEMATICOFFSET=EMPTY 

PLANAR(l).CONNECTORPOWER()=l 
CONNECTORPOWER(l).LOCATORTEXT=POWER INPUT 
CONNECTORPOWER(l ). SCHEMATICOFFSET=EMPTY 
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PLANAR(1).SCHEMATIC0=2 
SCHEMATIC(2).DESC=ATHENA Planar 
SCHEMATIC(2).FILE=ATHPLNR.JPG 
PLANAR(1).PICTURE0=2 
5 PICTURE(2).DESC=ATHENA Planar 

PICTURE(2).FILE=ATHPLNR.jpg 
PLANAR(1).SETTINGS0=1 :2 

SETTINGS( 1 ). APMBIO S=ENABLE (Indicates CMOS setting requested) 

SETTINGS( 1 ). ALT_BOOTSEQUENCE=ENABLE 
10 SETTINGS( 1 ).RESET_POC=ENABLE 

SETTINGS( 1 ).RUNIN=HALF_HR (Indicates desired test time) 

IDE(1).DESC=48X CDROM 

IDE(l).OPERATION=KITTING 

IDE(1).BOM_PN=09N0734 
$s IDE(l).TESTCLASS=cdrom_aud 
al IDE(1).CAPACITY=48X 
03 IDE(l).IDETYPE=CDROM 

i± DTAImage(l).DTA_FILE=BPl 13US.DTA (Name of file specifying preload content) 

+: DTAImage(l).TestClass=pdrvimg (Indicates process that will be used to preload) 

tfb CPU(1).DESC=INTEL P3 

CPU(l).OPERATION=CPL-KIT 
; = CPU(1).BOM_PN=09N9215 
O CPU(l).TESTCLASS=cpu 

2 CPU(1).SPEED=667_MHZ (CPU information (for SW verify)) 

m CPU(1).BUSSPEED=133_MHZ (CPU information (for SW verify)) 

ft? CPU(1).L1CACHE=32_KB (CPU information (for SW verify)) 

O CPU(1).L2CACHE=256_KB (CPU information (for SW verify)) 

^ CPU(l).SMBIOSTYPE=ll (CPU information (for SW verify)) 

CPU(l).SMBIOSDESIGNATION=CPUl 
30 MEM(1).DESC= 128MB DIMM 

MEM(l).OPERATION=CPL-KIT 

MEM(l).BOM_PN=38L28 18 

MEM( 1 ) . TE S TCL AS S=memory 

MEM(1).SPEED=60_NS (Memory information (for SW verify)) 

35 MEM( 1 ) . SIZE= 1 28 MB (Memory information (for SW verify)) 

MEM(l).ECC=NO (Memory information (for SW verify)) 

MEM(l). SMBIOSTYPE=3 (Memory information (for SW verify)) 

FDD(1).DESC=1.44MB FLOPPY 

FDD(l).OPERATION=UNIT-ASM 
40 FDD(1).BOM_PN=TSFD001 

FDD( 1 ).TESTCLAS S=fdd 

FDD(1).CAPACITY=1440_KB (FDD information (for SW verify)) 

FDD(1).PICTURE0=3 
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PICTURE(3).FILE=FLOPPY.JPG 
PICTURE(3).DESC=FLOPPY DRIVE 
IDE(2).DESC=20.4GB IDE HDD 
IDE(2).OPERATION=KITTING 
IDE(2).BOM_PN=09N0922 
EDE(2).TESTCLASS=hdd_ide 
K>E(2).CAPACITY=20.4_GB 
CABLEIDE(l). SCHEMATIC ()=3 
SCHEMATIC(3).DESC=IDE Cable 
SCHEMATIC(3).FILE=IDECbll.jpg 
CONNECTORIDE( 1 ). SCHEMATICOFFSET=empty 
CABLEIDE(1).DESC=1 DROP IDE CABLE 
C ABLEIDE( 1 ) . OPERATION=KITTING 
CABLEIDE(l).BOM_PN=33L3 132 
CABLEIDE(1).PICTURE0=4 
PICTURE(4).DESC=IDE Cable 
PICTURE(4).FTLE=IDECable.jpg 

CABLEIDE(l).CONNECTORIDE0=l 
CABLEIDE(l)CONNECTORDEVICEFILLTDE=HDDIDE 

C ABLEIDE( 1 ) . CONNECTORFILLIDE= 1 0 
CABLEIDE(l).CONNECTORLOCIDE=NO 
CONNECTORTDE( 1 ) .LOC ATORTEXT=IDE 1 
CONNECTORIDE( 1 ) . SETUP IDE=MASTER 
CABLEIDE(2). SCHEMATIC0=4 
SCHEMATIC(4).DESC=IDE Cable 
SCHEMATIC(4).FILE=IDECbl2.jpg 
CONNECTORIDE(2). SCHEMATICOFFSET=empty 
CONNECTORIDE(3). SCHEMATICOFFSET=empty 
CABLEIDE(2).DESC=2 DROP IDE CABLE 
CABLEIDE(2).OPERATION=KITTING 
CABLEIDE(2).BOM_PN=37L5001 
CABLEIDE(2).PICTURE0=5 
PICTURE(5).DESC=IDE Cable 
PICTURE(5).FILE=IDECable.jpg 
CABLEIDE(2).CONNECTORIDE0=2:3 

CABLEroE(2).CON^CTORDEVICEFILLIDE=HDDIDE,DVDIDE,CDIDE,TAPEIDE,ZI 
PIDE 

CABLEIDE(2).CONNECTORFILLIDE=30,40 
CABLEIDE(2) CONNECTORLOCIDE=NO 
CONNECTORIDE(2).LOCATORTEXT=IDE 1 
CONNECTORIDE(2). SETUPIDE=MASTER 
CONNECTORJDE(3).LOCATORTEXT=IDE 2 
CONNECTORTDE(3). SETUPIDE=SLAVE 
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PCI(2).DESC=LAKE CLARKE 2.4 ETHERNET CARD W AOL 

PCI(2).OPERATION=KITTING 

PCI(2).BOM_PN=34Ll 199 

PCI(2).TESTCLASS=lake_clarke 

PCI(2).VENDORID=8086 

PCI(2).DEVICEID=1229 

PCI(2).PICTURE0=6 

PICTURE(6).DESC= LAKE CLARKE PCI ETHERNET CARD 

PICTURE(6).FILE=ether.jpg 

AGP(l).DESC=PdVTOEO_S3AGP4X 

AGP(l).OPERATION=KITTING 

AGP( 1 ).BOM_PN=09N1 790 

AGP(l).TESTCLASS=number9_4X 

AGP(l).VENDORTD=5333 

AGP(1).DEVICEID=8A22 

AGP( 1 ) . VIDEOMEMOR Y= 1 6 MB 

AGP(1).PICTURE0=7 

PICTURE(7).DESC=S3 AGP Video 

PICTURE(7).FILE=S3AGP2.jpg 

POWER(l).DESC=POWER SUPPLY 

POWER(l).OPERATION=UNIT-ASM 

POWER(1).BOM_PN=TSPS001 

POWER(l).TESTCLASS=PowerSupply 

POWER(l).WATTAGE=145_WATTS 

POWER(1).CURRENT=20_AMPS 

POWER(l).VOLTAGE=l 15/220_VOLTS 

POWER(l).PICTURE0=8 

PICTURE(8).DESC=Power Supply 

PICTURE(8).FILE=Pwsup 1 jpg 

CONNECTORPCI(3).INSTALLEDDEVICE=PCI(2) (Indicates third pci connector gets 



CONNECTORFDD ( 1 ) . INS T ALLEDDE VICE=FDD( 1 ) (Indicates first floppy drive is 

plugged on first floppy connector) 

CONNECTORCPU(l).INSTALLEDDEVICE=CPU(l) 
CONNECTORMEM( 1 ) . INST ALLEDDE VICE=MEM( 1 ) 
CONNECTORMEM(2)TNSTALLEDDEVICE=EMPTY 
CONNECTORAGP(l)TNSTALLEDDEVICE=AGP(l) 
CONNECTORPCI( 1 ).INSTALLEDDEVICE=EMPTY 
CONNECTORPCI(2).INSTALLEDDEVICE=EMPTY 
CONNECTORC ABLEIDE( 1 ) . INS T ALLEDDE VICE=CABLEIDE( 1 ) 
CONNECTORCABLEIDE(2).INSTALLEDDEVICE=CABLEIDE(2) 
CONNECTORC ABLEFDD( 1 ) .INST ALLEDDE VICE=CABLEFDD( 1 ) 
CONNECTORPOWER(l).INSTALLEDDEVICE=POWER(l) 
CONNECTORIDE( 1).INSTALLEDDEVICE=IDE(2) 



PLANAR( 1). SYSBIOSLANGUAGE=US 



second pci card) 
(Indicates desired BIOS language) 
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CONNECTORIDE(2).INSTALLEDDEVICE=IDE( 1 ) 
CONNECTORIDE(3)JNSTALLEDDEVICE=EMPTY 

B AYPL ANAR( 1 ) .LOC ATEDDEVICE=PLANAR( 1 ) (Planar(l) is mounted in 

BayPlanar(l)) 

BAYPOWER(l).LOCATEDDEVICE=POWER(l) (Power(l) power supply is 

mounted in BayPower(l)) 

B AYFDD( 1 ).LOC ATEDDEVICE=FDD( 1 ) 
B AYHDD( 1 ).LOCATEDDEVICE=IDE(2) 
B AYD ASD 1 ( 1 ) LOC ATEDDEVICE=IDE( 1 ) 
B AYD ASD2( 1 ) . LOC ATEDDE VICE=EMPT Y 
EDynsunniic AOD Modification 

A key benefit of the AOD data model is that different processes in the fulfillment system 
can add to or alter the AOD stream. Thus, as the customer selects certain devices and options, the 
system can automatically generate AOD corresponding to proper configuration and population 
rules. That information need not be provided at the time of order entry, but rather is determined 
later during a post-order process that is transparent to the customer. 

Figure 1 illustrates a product fulfillment system 10 in accordance with one embodiment of 
the present invention. As is shown, a web based front end ordering system 20 allows the customer 
to select from a wide range of configuration options. The ordering system may capture part 
numbers requested and a small amount of personalization data, such as which PCI slots a customer 
wants the cards installed in, and some network settings. The personalization data is referred to as 
Customer AOD. The information obtained through the user interface is then passed into a Order 
Processing System 30. 

Here, the customer's product specifications are merged with population and configuration 
rules to form an AOD data stream. Configuration and population rules are stored in a database 
along with tables that associate part numbers to AOD; the part numbers have a one to one 
correspondence with components, and define the objects, attributes and values. Because the Order 
Processing System 30 has the ability to capture and convert the customer's specifications and 
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supplement that information to create an operable computer, the amount of information required 
from the customer is minimized. 

The AOD data stream emerging from the Order Processing System 30 is referred to as the 
Process AOD 40. This AOD fully and accurately describes the customized product requested by 
the customer. The Process AOD 40 is used in the automated manufacturing system 50, which 
includes several processes. For example, the automated manufacturing system 50 can include 
processes for creating assembly instructions 52, a process for automated testing 54, a process for 
automatically loading software 56, a customization process 58, and quality control 60. In addition, 
a service and support process 62 can be incorporated into the system 50. 

In a preferred embodiment, the automated manufacturing system's 50 processes can be 
software based. Each process understands and works off of the Process AOD 40. Because each of 
the processes 52-62 is specialized, the entire Process AOD 40 need not be transferred to each of 
the processes 52-62. A particular process, for example, the automated test process 54, can 
examine the Process AOD 40 and extract only those portions that are relevant to the test process 
54 function. Accordingly, the amount of data transfer through the automated manufacturing 
system 50 is minimized. 

In another embodiment, the assembly instructions process 52 uses the Process AOD 40 to 
create a pictorial form of the assembled product. For instance, instead of interpreting written 
assembly instructions, the assembly worker can be presented with a pictorial view of the device. 
This view can illustrate what particular components should be installed, how components should be 
connected, and where, i.e. which slot, a component should be placed. By presenting a picture of 
the assembled product, language barriers can be overcome, and worker confusion can be 
minimized. 
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Figure 2 is a flow diagram of a product fulfillment process 100 according to the present 
invention. In step 110, the process begins by obtaining the requirements, including configuration 
and personalized data, from the customer. This information is then used to create the Process 
AOD, via step 120. Step 120 is preferably an automated process which merges the information 
obtained from the customer with information stored in the database relating to configuration rules 
and population schemes. After the Process AOD is generated, it is used by the automated 
manufacturing system where the product is assembled, preloaded with software, and tested, via 
step 130. Finally, in step 140, the Process AOD is stored in a database for use by the service and 
support department to restore, repair, or replace hardware in the computer (e.g., correct BIOS 
levels, network settings, etc.). 

The object oriented approach and data model according to the present invention provides 
the ability to capture customer inputs from an ordering system and to transmit them to the 
manufacturing process without manual intervention or retyping of a free form, text based, order. It 
allows customers to specify a wide range of requested configuration options at order entry time to 
satisfy the customer's requirements. The present invention captures the order information 
accurately and completely, eliminating the need for follow-up calls with the customer to ask 
additional questions or for clarifications. 

The Process AOD provides a structured data format that can be used by all processes 
including ordering systems, manufacturing, assembly, manufacturing test, preload, quality, and 
service/support. Because of the modular nature of AOD, new products and components can easy 
be added to the system. Thus, rather than having to create and release a new model to specify new 
groupings of hardware, software, or other options, the object oriented data model allows a 
modular, building block approach. Finally, because customization and personalization data can be 
MPS9200001 10US 1 -2 1 - 




PATENT 

accurately captured without requiring separate part numbers, the number of part numbers that must 
be released by a development team is reduced. 

Although the present invention has been described in accordance with the embodiments 
shown, one of ordinary skill in the art will readily recognize that there could be variations to the 
embodiments and those variations would be within the spirit and scope of the present invention. 
Accordingly, many modifications may be made by one of ordinary skill in the art without departing 
from the spirit and scope of the appended claims. 
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